Sending emails for certain attributes

Hi there

I am working on an email notification system for my company. In doors, there are a multitude of things that cause a suspect link flag to be raised. Out of all the things that can cause a suspect link, the only editable attributes I care about are Object text and type, req allocation and safety of flight. I want a system to email me when any of those 4 attributes are modified and a suspect link is raised. Outlook is our email service and I am just curious as to how anyone thinks I could go about accomplishing this.
seth.wadd - Tue May 18 09:42:04 EDT 2010

Re: Sending emails for certain attributes
llandale - Tue May 18 10:57:26 EDT 2010

If yous set up your database to allow Email notification, you could perhaps do this. Install a post-save-attribute trigger in the Project. The trigger figures out the module and can decide this module doesn't qualify. The trigger figures out the name of the attribute just modified, and ignores all those except the 3 your want. The Trigger follows the incoming link, opening the source module and gets the source object, and figures out who cares that this link is now suspect (perhaps the source Book Boss). It then uses sendEmailNotification to that user.

Problem is, all those modules get left open.

If it were me, I'd write an on-demand batch script scheduled to run every night, looking for suspect links that featured changes in the attributes you want. It accumulates an email for each person affected by any such links. After browsing all objects in all modules in your Project and accumulating 'notices', it sends one email to each affected user, listing all such suspect links that user cares about. Narrowing down which attributes is performed by browsing the History of the target object looking for changes to your attributes, getting the History date, and comparing it to some 'Suspect Link' Date link-attribute whose name escapes me.

  • Louie

Here is one I did years ago...
pete.giorgianni - Wed May 26 08:01:50 EDT 2010

FYI...it comes as is. :)
Attachments

attachment_14470673_setEmailTrigv3_2.dxl

Re: Here is one I did years ago...
Mathias Mamsch - Wed May 26 08:53:40 EDT 2010

pete.giorgianni - Wed May 26 08:01:50 EDT 2010
FYI...it comes as is. :)

Hey Pete,

thanks for contributing! Some notes regarding your code:
  

// in a persistent trigger don't do this: 
Object o = current 
 
// instead do this: 
Trigger T = current
if (null T) halt
Object o = object T; if (null o) halt
Module m = module T; if (null m) halt

 


Using the current Object is wrong - when a script changes the attributes, then the trigger will take the current Object instead of the changed object, which you can aquire by Object object (Trigger). the same is true for current Module. Use Module module (Trigger) instead. When people take your code and install the trigger for all attributes they might run into the problem that if a module attribute is changed o = object T will return null and (identifier o) will fail with a DXL error. So always check for NULL values in a trigger. When doing persistent triggers, you also might want to think about Link Modules (yes they can also have triggers!), usually you want to do nothing for those.

In your code these points will probably be no problem. But if other people copy your code and change it, they will run into those problems.

Finally: Don't use "ack" or "confirm" or something in a trigger unless it is really necessary. Once a script will overwrite 10000 objects with values, you can restart your DOORS since it will be blocked by popup messages of your trigger. This can cause data loss.

Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: Here is one I did years ago...
pete.giorgianni - Wed May 26 11:35:16 EDT 2010

Mathias Mamsch - Wed May 26 08:53:40 EDT 2010

Hey Pete,

thanks for contributing! Some notes regarding your code:
  

// in a persistent trigger don't do this: 
Object o = current 
 
// instead do this: 
Trigger T = current
if (null T) halt
Object o = object T; if (null o) halt
Module m = module T; if (null m) halt

 


Using the current Object is wrong - when a script changes the attributes, then the trigger will take the current Object instead of the changed object, which you can aquire by Object object (Trigger). the same is true for current Module. Use Module module (Trigger) instead. When people take your code and install the trigger for all attributes they might run into the problem that if a module attribute is changed o = object T will return null and (identifier o) will fail with a DXL error. So always check for NULL values in a trigger. When doing persistent triggers, you also might want to think about Link Modules (yes they can also have triggers!), usually you want to do nothing for those.

In your code these points will probably be no problem. But if other people copy your code and change it, they will run into those problems.

Finally: Don't use "ack" or "confirm" or something in a trigger unless it is really necessary. Once a script will overwrite 10000 objects with values, you can restart your DOORS since it will be blocked by popup messages of your trigger. This can cause data loss.

Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Great points. Thanks!!